SRTP using DTLS Protocol
For SBC calls, you can configure the device to use the Datagram Transport Layer Security (DTLS) protocol to secure UDP-based traffic (according to RFC 4347 and 6347) for specific SIP entities, using IP Profiles. DTLS allows datagram-based applications to communicate in a way that is designed to prevent eavesdropping, tampering or message forgery. The DTLS protocol is based on the stream-oriented TLS protocol, providing similar security. The device can therefore interwork in mixed environments where one network may require DTLS and the other may require Session Description Protocol Security Descriptions (SDES) or even non-secure RTP. The device supports DTLS negotiation for RTP-to-SRTP and SRTP-to-SRTP calls.
DTLS support is important for deployments with WebRTC. WebRTC requires that media channels be encrypted through DTLS for SRTP key exchange. Negotiation of SRTP keys through DTLS is done during the DTLS handshake between WebRTC client and peer. For more information on WebRTC, see WebRTC.
In contrast to SDES, DTLS key encryption is done over the media channel (UDP) and not over the signaling channel. Thus, DTLS-SRTP is generally known as "secured key exchange over media". DTLS is similar to TLS, but runs over UDP, whereas TLS is over TCP. Before the DTLS handshake, the peers exchange DTLS parameters (fingerprint and setup) and algorithm types in the SDP body of the SIP messages exchanged for establishing the call (INVITE request and response). The peers participate in a DTLS handshake during which they exchange certificates. These certificates are used to derive a symmetric key, which is used to encrypt data (SRTP) flow between the peers. A hash value calculated over the certificate is transported in the SDP using the 'a=fingerprint' attribute. At the end of the handshake, each side verifies that the certificate it received from the other side fits the fingerprint from the SDP. To indicate DTLS support, the SDP offer/answer of the SIP message uses the 'a=setup' attribute. The 'a=setup:actpass' attribute value is used in the SDP offer by the device. This indicates that the device is willing to be either a client ('act') or a server ('pass') in the handshake. The 'a=setup:active' attribute value is used in the SDP answer by the device. This means that the device wishes to be the client ('active') in the handshake.
a=setup:actpass
a=fingerprint: SHA-1 \4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
DTLS cipher suite reuses the TLS cipher suite. The DTLS handshake is done for every new call configured for DTLS. In other words, unlike TLS where the connection remains "open" for future calls, a new DTLS connection is required for every new call. Note that the entire authentication and key exchange for securing the media traffic is handled in the media path through DTLS. The signaling path is used only to verify the peers' certificate fingerprints. DTLS messages are multiplexed onto the same ports that are used for the media.
|
2.
|
Open the IP Groups table (see Configuring IP Groups), and then for the IP Group associated with the SIP entity, assign it the TLS Context for DTLS, using the 'Media TLS Context' parameter. |
|
3.
|
Open the IP Profiles table (see Configuring IP Profiles), and then for the IP Profile associated with the SIP entity, configure the following: |
|
●
|
Configure the 'SBC Media Security Mode' parameter to Secured or Both. |
|
●
|
Configure the 'Media Security Method' parameter to DTLS. |
|
●
|
Configure the 'RTCP Mux' parameter to Supported. Multiplexing is required as the DTLS handshake is done for the port used for RTP and thus, RTCP and RTP must be multiplexed onto the same port. |
|
●
|
Configure the ini file parameter [SbcDtlsMtu] (or CLI command configure voip > sbc settings > sbc-dtls-mtu) to define the maximum transmission unit (MTU) size for the DTLS handshake. |
|
4.
|
Configure the minimum interval that the device waits between transmission of DTLS packets in the same DTLS handshake, using the ini file parameter [DTLSTimeBetweenTransmissions]. |
|
●
|
The 'Cipher Server' parameter must be configured to "ALL". |
|
●
|
The device doesn't support forwarding of DTLS transparently between endpoints. |